세미프로젝트1_03_대시보드와 DB 마이그레이션

GitHub: tricrawl

시각화 준비

너무 짧은 기간이다. 남은 시간이 많지 않았다.
이제 크롤링한 데이터를 대시보드로 보여주고 거기에 인텔리전스를 붙이는 것을 목표하기로 했다.

기본 뼈대는 내가 이미 잡아놓은 상태니까 대시보드 구축은 팀장이 맡기로 했다.
팀장이 Apache Superset을 쓰겠다고 했는데, 이런 작은 프로젝트 규모에 Superset은 좀 과하다 싶었다.
무겁고 설정도 복잡하한 데다 커스텀이나 확장이 자유롭지 않으니까.
지금은 시각화만 하면 되지만 나중에 대시보드 자체를 좀 꾸미거나, 외부 API 연결 같은 걸 붙이려 하면 어려울 게 뻔했다.

Grafana를 쓰는게 정답이다. 가볍고 데이터소스 연결이 유연하고, Prometheus나 PostgreSQL 같은 소스를 플러그인 하나로 물릴 수도 있다.
알림 시스템도 기본 내장이다. 대시보드 커스터마이징도 JSON 모델 기반이라 확장하기 편하다.
커뮤니티 규모도 압도적이라서 막히면 검색 한 번으로 해결되는 경우가 많다.

근데 뭐, 하겠다는 걸 내가 굳이 뭐라 할 이유가 없다. 맡겼으면 믿어야지.
확장성 문제가 나중에 터지면 그때 가서 해결하면 된다. 지금 수준에 터질만한 문제도 없긴 하다.
어쨌든 내가 더 나은 방법을 알고 있어도, 구성원의 선택을 존중하는 것도 협업의 일부다.

나머지 팀원들은 대시보드에 붙일 인텔리전스를 어떻게 구성할지 각자 준비해오기로 했다.
키워드 분석을 할 건지 위협 수준 분류를 할 건지 아니면 트렌드 시각화를 할 건지.
방향성을 잡아와야 대시보드 설계도 거기에 맞출 수 있으니까.

나는 그것과 더불어 DB를 갈아엎기로 했다.

json에서 Supabase로

지금까지는 크롤링 데이터를 json 기반 로컬 DB에 저장하고 있었다.
스키마 고민 없이 딕셔너리 만들어서 dump하면 끝이니까 프로토타이핑에는 좋다.

하지만 이제 팀원 간 데이터 공유나 대시보드 연결을 생각해야 하니 DB 마이그레이션은 당연한 수순이었다.
자주 쓰던 Supabase로 마이그레이션하기로 했다.
PostgreSQL 기반이라 복잡한 쿼리도 자유롭게 날릴 수 있고 REST API가 자동으로 생성되니까 대시보드에서 바로 물리기 좋다.

문제는 이제.... 리팩토링인데, 프로토타이핑에서 json 파일을 직접 읽고 쓰는 부분을 모두 수정해야 했다.
스토리지 레이어를 분리해두긴 했는데 그래도 고쳐야 할 곳이 적지 않았다.
크롤러의 파이프라인 출력 부분부터 데이터 조회 로직까지 스키마를 새로 설계하고, 기존 json 데이터를 변환 스크립트로 밀어넣고 코드를 하나씩 손봤다.

Supabase에 데이터가 올라가니까 대시보드에서 바로 끌어올 수 있게 됐고 그걸 기반으로 대시보드 구축까지 끝냈다.
실시간으로 크롤링 현황이 갱신되는 걸 볼 수 있었다.

프로젝트 초반에 하는게 좋았을까?
사실 내가 아키텍쳐를 혼자 해야할 줄도 몰랐고, 시간도 부족했고, 어쩔 수 없었다. 프로토타이핑이 빨라야 했으니까.
결과적으로 크게 문제는 없었지만, 다음부터는 처음부터 운영 DB를 깔고 가야겠다는 생각이 든다.